Skip to main content
QMSQMS
QMS
  • Welcome to your QMS
  • Quality Manual
  • Procedures
  • Records
  • TF_Legit.Health_Plus
    • Legit.Health Plus TF index
    • Legit.Health Plus STED
    • Legit.Health Plus description and specifications
    • R-TF-001-007 Declaration of conformity
    • GSPR
    • Clinical
    • Design and development
    • Design History File (DHF)
      • Version 1.1.0.0
        • Requirements
          • REQ_001 The user receives quantifiable data on the intensity of clinical signs
          • REQ_002 The user receives quantifiable data on the count of clinical signs
          • REQ_003 The user receives quantifiable data on the extent of clinical signs
          • REQ_004 The user receives an interpretative distribution representation of possible ICD categories represented in the pixels of the image
          • REQ_005 The user can send requests and get back the output of the device as a response in a secure, efficient and versatile manner
          • REQ_006 The data that users send and receive follows the FHIR healthcare interoperability standard
          • REQ_007 If something does not work, the API returns meaningful information about the error
          • REQ_008 Notify the user if the image does not represent a skin structure
          • REQ_009 Notify the user if the quality of the image is insufficient
          • REQ_010 The device detects if the image is of clinical or dermatoscopic modality
          • REQ_011 The user specifies the body site of the skin structure
          • REQ_012 Users can easily integrate the device into their system
          • REQ_013 The user receives the pixel coordinates of possible ICD categories
          • ignore-this
            • SWR-001- Users of the REST API can log in and receive an access token
            • SWR-002- The REST API enforces HTTPS for all communications to ensure data security
            • SWR-003- The REST API implements rate limiting to prevent abuse
            • SWR-004- The REST API verifies the access token for every request to secure endpoints
            • SWR-005- Data exchanged with clinical endpoints of the API adhere to the FHIR standard
            • SWR-006- The REST API only accepts and outputs images in Base64 format
            • SWR-007- The diagnosis support service accepts multiple images to deliver more accurate results
            • SWR-008- The user's password is stored in the database as a hashed password
            • SWR-009- New users of the device are only created by an internal user registration service
          • software-design-specification
          • software-requirement-specification
          • user-requirement-specification
        • Test plans
        • Test runs
        • Review meetings
        • 🥣 SOUPs
    • IFU and label
    • Post-Market Surveillance
    • Quality control
    • Risk Management
  • Licenses and accreditations
  • External documentation
  • TF_Legit.Health_Plus
  • Design History File (DHF)
  • Version 1.1.0.0
  • Requirements
  • ignore-this
  • SWR-008- The user's password is stored in the database as a hashed password

SWR-008- The user's password is stored in the database as a hashed password

Internal IDSWR_008
TitleThe user's password is stored in the database as a hashed password
CategorySECURITY REGULATORY
ImportanceCRITICAL
SystemBackend, Database
Editor(s)Alejandro Carmena Magro , JD-017
SupervisorAlfonso Medela , JD-005
ApprovalPENDING
Created at24 Jun 2024

Description​

For user authentication, passwords are stored either as plaintext or hashes. Since passwords stored as plaintext are easily stolen if database access is compromised, databases typically store hashes instead. Thus, no one (including the authentication system) can learn a password merely by looking at the value stored in the database.

When we create a new account for a user or they update their password, the plaintext password is first combined with a unique salt value. This salt is a random string of characters that is unique to each password and helps to protect against rainbow table attacks. The combined password and salt are then passed through a hashing algorithm, which converts the input into a fixed-length string of characters. The output, known as the hash, does not reveal the original password and is computationally infeasible to reverse. This hashed password, along with the salt, is then stored in the database. Each time a user logs in, the software hashes the entered password with the stored salt and compares the result to the stored hash to verify the user's identity without ever needing to store or transmit the plaintext password.

Rationale​

This requirement significantly improves the security of user data. Storing passwords as plaintext poses a severe security risk, as any breach of the database would expose user credentials. Hashing passwords mitigates this risk by ensuring that even if the database is compromised, the actual passwords remain protected.

Source​

  • Alejandro Carmena Magro , JD-017
  • Regulatory standards (e.g., GDPR)
  • Industry best practices

Tested by software tests​

  • PLAN_015: Password hashing during user registration
  • PLAN_016: Password hash comparison during login

Activities generated​

  • Incorporating a secure hashing algorithm (e.g., bcrypt, Argon2) in the backend code.
  • Configuring the user registration and password update workflows to include hashing.

Implements user needs​

This requirement guarantees the security and privacy of user accounts, addressing concerns about personal information safety and boosting trust in the software.

Regulatory requirements​

8.1: The device shall be compliant with MDR 2017/745, Annex I, point 17.2, 17.4, 18.8, 23.4(ab).

8.2: The device shall be compliant with data privacy regulation (Regulation (EU) 2016/679 (General Data Protection Regulation)).

Causes failure modes​

  • Incorrect implementation or usage of the hashing algorithm could result in weak security.
  • Failure to properly hash passwords before storage could leave plaintext passwords exposed.

Implements risk control measures​

  • Hashing passwords helps protect against credential stuffing attacks, where attackers use leaked usernames and passwords from one service to try to gain access to other services.
  • Even if an insider gains access to the database, they cannot easily retrieve plaintext passwords, thus reducing the risk from internal threats.
  • Storing passwords in a hashed format helps in complying with various regulatory requirements like GDPR, HIPAA, and others.
  • A security breach exposing plaintext passwords can severely damage the reputation of the organization. Using hashed passwords helps mitigate the potential damage to the company's reputation in case of a data breach.

Acceptance criteria​

  • All user passwords are hashed before storage in the database.
  • The hashing algorithm used must be a recognized secure method (e.g., bcrypt, Argon2).
  • Unit and integration tests demonstrating that plaintext passwords are not stored in the database.

Constraints​

  • The chosen hashing algorithm must balance security and performance, ensuring it is robust enough to resist attacks while not introducing excessive computational overhead in user authentication processes.

Dependencies​

  • Availability of cryptographic libraries (such as OpenSSL, Bcrypt, Argon2) to provide the hashing algorithms.
  • Database management system.
  • User account management system.
  • User authentication system.

Performance considerations​

  • The hashing process should not significantly degrade the performance of login operations.

Additional notes​

Regularly review and update the hashing algorithm to align with the latest security recommendations.

Revision history​

Document versionDateAuthorDescription
Previous
SWR-007- The diagnosis support service accepts multiple images to deliver more accurate results
Next
SWR-009- New users of the device are only created by an internal user registration service
  • Description
  • Rationale
  • Source
  • Tested by software tests
  • Activities generated
  • Implements user needs
  • Regulatory requirements
  • Causes failure modes
  • Implements risk control measures
  • Acceptance criteria
  • Constraints
  • Dependencies
  • Performance considerations
  • Additional notes
  • Revision history
All the information contained in this QMS is confidential. The recipient agrees not to transmit or reproduce the information, neither by himself nor by third parties, through whichever means, without obtaining the prior written permission of Legit.Health (AI LABS GROUP S.L.)